I claim that for understanding a business, you should understand its information – what it deals with – the information it creates while it produces its product. Others may argue that the processes are the most important part – but I differ. If you know the information first, you know – or can figure out - what processes must be present that create this information. If you just know the processes, you still do not really know the information.

As a software architect, you can use the phrase “follow the information” in the same sense as detectives of crime use “follow the money”. You will find the truth this way.

When you follow information, it is easy for all to see if it is valuable information or not, but when following processes, you track work that is performed currently. Suppose you found an unneeded process step – how will you know that it is unneeded? You cannot get a correct answer from the ones performing it now – since they are biased that it is important - and no one else will have enough information to really know.

If you learn the important information first, you can easily see what the process step at hand does to that information. It should evolve the information in some way. If it does not create or change information in a valuable way the process step is unnecessary – for this business at least.

The Information

There are many ways to describe Information. My recommendation is UML – the Unified Modeling Language. UML contains a set of rules – and it lets you describe everything you need without further need for interpretation. UML is the core defining the models available in MDriven. This book will use UML extensively.

The MDriven Book - Next Chapter: Short introduction to UML– class diagram